Communication devices and methods for generating a message

ABSTRACT

According to one embodiment, a communication device is described that comprises a determining circuit configured to determine a type of an information indicated by a first message, wherein the first message is formed in accordance with a first transmission protocol; a selecting circuit configured to select a type of message according to a second transmission protocol based on the determined type of information; and a message generating circuit configured to generate a second message of the selected type according to the second transmission protocol indicating the information.

TECHNICAL FIELD

Embodiments generally relate to communication devices and methods forgenerating a message.

BACKGROUND

Unstructured Supplementary Service Data (USSD) is a protocol that may beused by cellular telephones to communicate with a component of thenetwork side. The efficient transmission of supplementary service datain accordance with USSD is desirable.

BRIEF DESCRIPTION OF THE DRAWINGS

In the drawings, like reference characters generally refer to the sameparts throughout the different views. The drawings are not necessarilyto scale, emphasis instead generally being placed upon illustrating theprinciples of the invention. In the following description, variousembodiments are described with reference to the following drawings, inwhich:

FIG. 1 shows a communication device according to an embodiment.

FIG. 2 shows a flow diagram according to an embodiment.

FIG. 3 shows a communication device according to an embodiment.

FIG. 4 shows a flow diagram according to an embodiment.

FIG. 5 shows a communication system according to an embodiment.

FIG. 6 shows a flow diagram according to an embodiment.

FIG. 7 shows a flow diagram according to an embodiment.

FIG. 8 shows a flow diagram according to an embodiment.

FIG. 9 shows a communication system according to an embodiment.

FIG. 10 shows a flow diagram according to an embodiment.

DESCRIPTION

The following detailed description refers to the accompanying drawingsthat show, by way of illustration, specific details and embodiments inwhich the invention may be practiced. These embodiments are described insufficient detail to enable those skilled in the art to practice theinvention. Other embodiments may be utilized and structural, logical,and electrical changes may be made without departing from the scope ofthe invention. The various embodiments are not necessarily mutuallyexclusive, as some embodiments can be combined with one or more otherembodiments to form new embodiments.

Unstructured supplementary service data is a transmission protocol thatallows the exchange of data between a communication terminal of acommunication system and a component of the network side of thecommunication system, e.g. a radio access network and/or a core networkof a cellular mobile communication system wherein the communicationterminal is a subscriber terminal of the cellular mobile communicationsystem.

In USSD Man Machine Interface mode (MMI mode) data may be transmittedthat can be used to exchange generic information between a communicationterminal and a component of the network side. For example, acommunication terminal may transmit data according to USSD to requestspecial information from the component of the network side and thecomponent of the network side may transmit information data to bedisplayed by the communication terminal.

In USSD application mode data may be transmitted that can be used toexchange application specific information between a communicationterminal and a component of the network side. For example, informationmay be exchanged for controlling a network based voice mail box for thecommunication terminal.

A USSD message can contain up to 182 7 bit characters.

In a mobile communication system according to 3GPP (3^(rd) GenerationPartnership Project) USSD data (i.e. USSD messages) may be transportedvia layer 3 signaling. According to USSD data are exchanged in (small)dialogs referred to as transactions. Such a dialog is identified by atransaction identifier (id). According to USSD, data are immediatelytransmitted (without store and forward).

According to one embodiment, a possibility is provided to transport USSDmessages in a communication network that is not necessarily based on a3GPP communication network. For example, according to one embodiment, atransport mechanism is provided that is applicable to an IMS (InternetProtocol Multimedia Subsystem) that is not necessarily provided with a3GPP communication network. According to one embodiment, a possibilityfor immediate transport of USSD messages is provided. Further, accordingto one embodiment, a possibility for efficient transport (e.g. with lowsignaling overhead) is provided. According to one embodiment, atransport mechanism is provided that is compliant with IETF (InternetEngineering Task Force).

According to one embodiment, information indicated by a USSD message istransported (i.e. transmitted) using MSRP (Message Session RelayProtocol).

In other words, according to one embodiment, USSD is provided based onthe MSRP such that USSD messages can be transported in a communicationsystem capable of using the MSRP (e.g. an IMS).

The MSRP can be used to exchange messages within a messaging session,e.g. a multimedia session. Multimedia sessions can for example be set upand controlled using the Session Initiation Protocol (SIP), e.g. in anIMS which provides communication services based on SIP.

MSRP SEND messages can be used to transport messages. An entire messagemay be split into multiple chunks each being transported by an MSRP SENDmessage.

MSRP REPORT messages may be used to respond with delay to MSRP SENDmessages.

According to one embodiment, a communication system supporting MSRP (butnot providing 3GPP layer 3 signaling) can be used to transport USSDmessages. Thus, according to one embodiment, supplementary services tobe used in a communication system not providing 3GPP layer 3 signalingcan be based on USSD and existing USSD based supplementary services canbe used in a communication system not providing 3GPP layer 3 signaling.According to one embodiment USSD messages can be immediately transmittedvia MSRP and can be transmitted efficiently (e.g. with low signalingoverhead). Further, according to one embodiment, USSD message transportvia MSRP is compliant with the IETF specifications. According to oneembodiment, USSD messages are transported using existing MSRP messagessuch that no new MSRP messages need to be specified.

Generally, according to one embodiment, a message according to a firsttransmission protocol (e.g. USSD) may be transmitted by a communicationdevice by means of a message according to a second transmission protocol(e.g. MSRP) in a way that may allow efficient transmission of themessage according to the first transmission protocol (or, in otherwords, the information indicated by the message according to the firsttransmission protocol). A communication device according to anembodiment is described in the following with reference to FIG. 1.

FIG. 1 shows a communication device 100 according to an embodiment.

The communication device 100 includes a determining circuit 101configured to determine, for a first message formed in accordance with afirst transmission protocol indicating information to be transmitted aspart of a message exchange, whether or not the first message is amessage directed to an initiator of the message exchange (e.g. a messagedialog such as a USSD transaction).

The communication device 100 further includes a selecting circuit 102configured to select a type of message according to a secondtransmission protocol based on whether or not the first message isdirected to the initiator of the message exchange and a messagegenerating circuit 103 configured to generate a second message of theselected type according to the second transmission protocol indicatingthe information.

According to one embodiment, in other words, a message according to afirst protocol is translated into a message according to a secondprotocol, wherein the type of message of the second protocol that isused depends on to whom the information indicated by the first messageis addressed, namely whether to the initiator of the message exchange incourse of which the information is to be transmitted or to anon-initiator of the message exchange in course of which the informationis to be transmitted. In other words, different types of messages of thesecond protocol are used for different transport directions of theinformation to be exchanged during the message exchange.

It should be noted that the first message does not necessarily need tobe present in the communication device 100 (i.e. does not necessarilyhave to be generated by the communication device 100 or have to havebeen received by the communication device 100). In other words, thesecond message may be generated for a content, structure, and/orrecipient of the first message that it would have if the firsttransmission protocol was used for transmission of the information.

In an embodiment, a “circuit” may be understood as any kind of a logicimplementing entity, which may be special purpose circuitry or aprocessor executing software stored in a memory, firmware, or anycombination thereof. Thus, in an embodiment, a “circuit” may be ahard-wired logic circuit or a programmable logic circuit such as aprogrammable processor, e.g. a microprocessor (e.g. a ComplexInstruction Set Computer (CISC) processor or a Reduced Instruction SetComputer (RISC) processor). A “circuit” may also be a processorexecuting software, e.g. any kind of computer program, e.g. a computerprogram using a virtual machine code such as e.g. Java. Any other kindof implementation of the respective functions which will be described inmore detail below may also be understood as a “circuit” in accordancewith an alternative embodiment.

The first transmission protocol and/or the second transmission protocolsare for example application layer protocols, i.e. protocols of the OSI(Open Systems Interconnection) reference model application layer.

According to one embodiment, the communication device further includes atransmitter configured to send the generated second message.

According to one embodiment, the determining circuit is configured todetermine whether the first message is directed to the initiator or to anon-initiator of the message exchange.

According to one embodiment, the information is included in the firstmessage.

According to one embodiment, the message generating circuit isconfigured to generate the second message to include the information.

According to one embodiment, the second protocol is the Message SessionRelay Protocol (MSRP).

According to one embodiment, the first protocol is the UnstructuredSupplementary Service Data (USSD) protocol.

According to one embodiment, the message exchange is an UnstructuredSupplementary Service Data transaction.

According to one embodiment, the message exchange is carried out in acommunication session (e.g. a communication session set up with SIP).

The message exchange is for example carried out between thecommunication device and another communication device.

The communication device is for example a communication terminal.

The communication device may also be a communication server on thenetwork side of a communication system. The communication device mayoperate as a gateway between two communication systems.

The communication device 100 for example carries out a method asillustrated in FIG. 2.

FIG. 2 shows a flow diagram 200 according to an embodiment.

The flow diagram 200 illustrates a method for generating a message.

In 201 it is determined, for a first message formed in accordance with afirst transmission protocol indicating information to be transmitted aspart of a message exchange, whether or not the first message is amessage directed to an initiator of the message exchange.

In 202 a type of message according to a second transmission protocol isselected based on whether or not the first message is directed to theinitiator of the message exchange.

In 203, a second message of the selected type is generated according tothe second transmission protocol indicating the information.

In case that the second transmission protocol allows separation of amessage in a plurality of parts (which are all associated with the samemessage by means of an identification of the message), which is alsoreferred to as “chunking”, such as it is the case for MSRP, a pluralityof messages according to the first protocol are according to oneembodiment sent using a plurality of parts of the same message accordingto the second protocol. This is illustrated in FIG. 3.

FIG. 3 shows a communication device 300 according to an embodiment.

The communication device 300 includes a message generating circuit 301configured to generate, for each first message of a sequence of firstmessages formed in accordance with a first application layertransmission protocol indicating an information, a part of a secondmessage according to a second application layer transmission protocolindicating the information, wherein the parts of the second messageaccording to the second application layer transmission protocol eachinclude an identification of the second message.

According to one embodiment, in other words, the first messages aretranslated to parts of the same second message according to the secondprotocol. These parts are also referred to as “chunks” of the secondmessage. Similarly, response messages to the parts of the second messagemay be received as parts (chunks) of one (overall) response message. Inother words, a dialog between the communication device and anothercommunication device (providing the response messages) may be carriedout using only two (overall) messages (namely the second message and theoverall response message by the other communication device) which areseparated into chunks. This allows carrying out a message dialogaccording to the second protocol without need of a communication sessionin which a plurality of messages are sent and received by both sides.The first protocol and the second protocol are in this embodimentsapplication layer protocols, i.e. protocols of the application layeraccording to the OSI (Open Systems Interconnection) reference model. Thechunks include a common identification, namely an identification of thesecond message, which may in case that the first protocol is USSD forexample correspond to a USSD transaction id.

According to one embodiment, the communication device further includes atransmitter configured to transmit the parts of the second message.

The transmitter is for example configured to transmit the parts of thesecond message in a communication session.

According to one embodiment, the communication device further includes areceiver configured to receive a response message to at least one partof the second message.

According to one embodiment, the message generating circuit isconfigured to generate the parts of the second message such that asequence of parts of the second message corresponding to the sequence offirst messages is generated and is configured to generate, for the atleast one part of the second message, the part of the second messageonly after the response message to the part of the second messagepreceding the part of the second message in the sequence of parts of thesecond message has been received by the receiver.

According to one embodiment, the message generating circuit isconfigured to, for the at least one part of the second message, generatethe part of the second message in response to the response message.

The communication device may further include a receiver configured toreceive a response message to each part of the second message.

According to one embodiment, the message generating circuit isconfigured to generate the parts of the second message such that asequence of parts of the second message corresponding to the sequence offirst messages is generated and is configured to generate, for each partof the second message but the first part in the sequence of parts of thesecond message, the part of the second message only after the responsemessage to the part of the second message preceding the part of thesecond message in the sequence of parts of the second message has beenreceived by the receiver.

The communication device for example carries out a method as illustratedin FIG. 4.

FIG. 4 shows a flow diagram 400 according to an embodiment.

The flow diagram 400 illustrates a method for generating a message.

In 401, for each first message of a sequence of first messages formed inaccordance with a first application layer transmission protocolindicating an information, a part of a second message according to asecond application layer transmission protocol is generated indicatingthe information, wherein the parts of the second message according tothe second application layer transmission protocol each include anidentification of the second message.

It should be noted that embodiments described in context of one of thecommunication devices are analogously valid for the other communicationdevice and the methods for generating a message and vice versa.

Further, it should be noted that the communication devices and methodsfor generating a message as described above with reference to FIGS. 1 to4 can be used independently and may also be combined according tovarious embodiments.

According to one embodiment, the first transmission protocol is USSDand/or the second transmission protocol is MSRP. Thus, according to oneembodiment, MSRP messages are used for transporting USSD data (i.e. USSDmessages) in a communication system. For this, according to oneembodiment, an MSRP session is being set up for USSD communication. AUSSD transaction is translated to the chunks of a message to betransmitted by MSRP SEND messages (e.g. for the USSD messages generatedby the initator of the message dialog) and MSRP REPORT messages (e.g.for the USSD response messages to be returned to the initiator of themessage dialog). The USSD transaction identifier (id) is for examplemapped to the MSRP Message-ID header value. A component of the networkside may provide its MSRP address for the USSD service during sessionsetup. A communication terminal may according to one embodiment choose atarget network address depending on the USSD codes for networkindication.

According to one embodiment, for interworking of a communication systemsupporting MSRP with a communication system that does not support MSRP(but supports USSD by other means) a gateway may be provided translatingbetween USSD messages and MSRP messages. In other words, thecommunication devices according to FIGS. 1 and 3 may be operated as sucha gateway.

According to one embodiment, for interworking with USSD basedapplications an IM client (e.g. running on a communication terminal)and/or an IMS server can be provided for translating between USSDmessages and MSRP messages. In other words, the communication devicesaccording to FIGS. 1 and 3 may be operated as an IMS client or as an IMSserver.

According to one embodiment, USSD REGISTER messages may be translated toMSRP SEND messages. USSD FACILITY messages may be translated to MSRPSEND or MSRP REPORT messages. USSD RELEASE COMPLETE messages may betranslated to MSRP SEND or MSRP REPORT messages. USSD response messagesmay be translated to MSRP SEND messages or MSRP REPORT messages or MSRPresponse messages.

In the following, examples are given for transporting USSD messageinformation by means of MSRP.

FIG. 5 shows a communication system 500 according to an embodiment.

The communication system 500 is an IMS communication system, i.e. acommunication system based on IMS. It includes a communication terminal501, in other words an end device, for example a mobile terminal, and avisited (IMS) network 502, i.e. an IMS network which is not operated bythe operator of the home network of the communication terminal 501. Thevisited network 502 includes a P-CSCF (Proxy-Call Session ControlFunction 503) and a first I-CSCF 504 (Interrogating-CSCF).

The communication system 500 further includes a home (IMS) network 505of the communication terminal 501 which includes a second I-CSCF 506, anS-CSCF (Serving-CSCF) 507 and a USSD AS (USSD Application Server) 508.

The communication terminal 501 is connected to the visited network'sProxy-CSCF (P-CSCF) 503. The P-CSCF 503 is connected to the homeoperator's Serving CSCF (S-CSCF) 507 via the first I-CSCF 504 and thesecond I-CSCF 506. The S-CSCF 507 is connected to the home operator'sUSSD application server 508.

In the following example, it is assumed that the user of thecommunication terminal 501 would like to enable call forwarding for hiscommunication terminal 501.

The user initiates the generation and sending of a USSD message usingthe communication terminal 501 to request call forwarding. The generatedUSSD message includes particular USSD codes indicating that the USSDmessage should be sent to the user's home network and indicating thatcall forwarding is requested.

The communication terminal 501 further initiates an MSRP session. Thecorresponding flow is illustrated in FIG. 6.

FIG. 6 shows a flow diagram 600 according to an embodiment.

The flow takes place between a communication terminal 601 correspondingto the communication terminal 501, a P-CSCF 602 corresponding to theP-CSCF 503, an S-CSCF 603 corresponding to the S-CSCF 507, and a USSD AS604 corresponding to the USSD AS 508.

In 605, the communication terminal 601 generates a SIP INVITE message606 for initiating an MSRP session. Since the USSD message includes theUSSD code for home network forwarding the communication terminal 601chooses the address of the home operator's USSD application server (AS)604 as target address for the SIP INVITE message 606. The address of thehome operator's USSD AS 604 has for example been provided beforehand tothe communication terminal 601 by the home network operator.

The SIP INVITE message 606 for example has the following structure:

INVITE sip:ussd@operator.com SIP/2.0     To: <sip:ussd@operator.com>    From: <sip:user@example.com>;tag=xfg9     Call-ID: 3413an89KU    Content-Type: application/sdp     c=IN IP4 ims.operator.com    m=message 7654 TCP/MSRP *     a=accept-types:text/plain    a=path:msrp://ussd.operator.com:7777/iau39soe2843z;tcp

The communication terminal 601 sends the SIP INVITE message 606 via theP-CSCF 602 and the S-CSCF 603 to the USSD AS 604. The USSD AS 604acknowledges the session setup in 608 by means of an 200 OK message 607which is in turn acknowledged by the communication terminal 601 by meansof an ACK message 610 in 609.

The further message flow after session setup is illustrated in FIG. 7.

FIG. 7 shows a flow diagram 700 according to an embodiment.

The message flow takes place between a communication terminal 701corresponding to the communication terminal 501, 601 and a USSD AS 702corresponding to the USSD AS 508, 604.

After session setup, in 703, the communication terminal 701 translatesthe USSD message into a first MSRP SEND message 704. The first MSRP SENDmessage 704 includes the USSD transaction identifier (id) as aMessage-ID header value. It also includes a ‘text/plain’ Content-Typebody including the USSD data. The Byte-Range header field is set to1-*/* to indicate that the first MSRP SEND message 704 provides thefirst of several message chunks and the total message size is unknown.The Success-Report header field is set to ‘yes’ to indicate that MSRPsuccess REPORT messages should be sent back.

The USSD message and the first MSRP SEND message 704 (into which theUSSD message is translated) for example have the following structure:

USSD message: Transaction identifier: 1234 Message type: RegisterFacility: Invoke = ProcessUnstructuredSS- Request, ussd-String =*12(5)#SEND MSRP message: MSRP dkei38sd SEND To-Path:msrp://ussd.operator.com:7777/iau39soe2843z;tcp From-Path:msrp://user.example.com:8888/9di4eae923wzd;tcp Message-ID: 1234Success-Report: yes Byte-Range: 1-*/* Content-Type: text/plainMessageType:Register Facility:Invoke = ProcessUnstructuredSS-Request,ussd-String = *12(5)#SEND -------dkei38sd+

Further, the communication terminal 701 sets up a Transmission ControlProtocol (TCP) connection to the USSD AS 702 for transporting MSRPmessages and associates the connection with the USSD MSRP session. ThisTCP connection for MSRP transport is indicated by a dashed arrow 509 inFIG. 5. The communication terminal 701 sends the first MSRP SEND message704 via the established TCP connection to the USSD AS 702 in 703.

In 705, when the USSD AS 702 receives the first MSRP SEND message 704 itresponds by means of a first MSRP 200 OK message 706 to acknowledge thereceipt of the MSRP SEND message 704.

In 707, the USSD AS 702 inspects the content of the first MSRP SENDmessage 704 for USSD codes. It finds the USSD service code for callforwarding.

The USSD AS 702 further finds that no destination for call forwardinghas been defined yet by the user. Therefore it generates a USSD messageto request the call forwarding destination from the communicationterminal 701. The USSD AS 702 translates the USSD message to a firstMSRP REPORT message 709 and sends the first MSRP REPORT message 709 tothe communication terminal 701 in 708.

The USSD message and the corresponding first MSRP REPORT message 709 forexample have the following structure:

USSD message: Transaction identifier: 1234 Message type: FacilityFacility: Invoke = UnstructuredSS-Request, ussd-String = *13(7)#SENDMSRP message: MSRP dkei38ia REPORT To-Path:msrp://user.example.com:8888/9di4eae923wzd;tcp From-Path:msrp://ussd.operator.com:7777/iau39soe2843z;tcp Message-ID: 1234Byte-Range: 1-88/88 Status: 000 200 OK Content-Type: text/plainMessageType:Facility Facility:Invoke = UnstructuredSS-Request,ussd-String = *13(7)#SEND -------dkei38ia$

When receiving the first MSRP REPORT message 709 the communicationterminal 701 knows from the connection association of the first MSRPREPORT message 709 with the USSD MSRP session that the first MSRP REPORTmessage 709 is for transporting USSD data. From the USSD transactionidentifier in the Message-ID header of the first MSRP REPORT message 709the communication terminal 701 knows that the transported USSD databelongs to the transaction initiated by the USSD call forwarding requestpreviously sent (with the first MSRP SEND message 704).

In 710, the communication terminal 701 inspects the content of the firstMSRP REPORT message 709 for USSD codes. It finds the code for requestingthe call forwarding destination and sends back a second MSRP SENDmessage 711 including a USSD body containing a USSD code for callforwarding destination and the destination URL.

The second MSRP SEND message 711 provides the second chunk of the entiremessage sent via MSRP whose first chunk has been sent in the first MSRPSEND message 704. This is indicated by a Byte-Range header field value‘89-*/*’.

The USSD message corresponding to the USSD body of the second MSRP SENDmessage 711 and the second MSRP SEND message 711 for example have thefollowing structure:

USSD message: Transaction identifier: 1234 Message type: FacilityFacility: Return result = UnstructuredSS- Request, ussd-String =*17(9)*tel:+1-201-555-0123#SEND MSRP message: MSRP dkei38sd SENDTo-Path: msrp://ussd.operator.com:7777/iau39soe2843z;tcp From-Path:msrp://user.example.com:8888/9di4eae923wzd;tcp Message-ID: 1234Success-Report: yes Byte-Range: 89-*/* Content-Type: text/plainMessageType:Facility Facility:Return result = UnstructuredSS-Request,ussd-String = *17(9)*tel:+1-201-555-0123#SEND -------dkei38sd+

In 712, the USSD AS 702 acknowledges the information about theforwarding destination by means of a second 200 OK message 713.

In 714, the USSD AS 702 sets the call forwarding destination for theuser to the URL provided by the second MSRP SEND message 711 and enablescall forwarding.

After the transaction has been completed the USSD AS 702 releases thetransaction by generating a USSD RELEASE COMPLETE message, translatingthe message to a second MSRP REPORT message 716 and sending the secondMSRP REPORT message to the communication terminal 701 in 715.

The USSD RELEASE COMPLETE message and the second MSRP REPORT message 716for example have the following structure:

USSD message: Transaction identifier: 1234 Message type: ReleaseComplete Facility: Return result = ProcessUnstructuredSS-Request,ussd-String = MSRP message: MSRP dkei38bv REPORT To-Path:msrp://user.example.com:8888/9di4eae923wzd;tcp From-Path:msrp://ussd.operator.com:7777/iau39soe2843z;tcp Message-ID: 1234Byte-Range: 89-*/* Status: 000 200 OK Content-Type: text/plainMessageType:Release Complete Facility:Return result =ProcessUnstructuredSS-Request, ussd- String = -------dkei38bv$

In one embodiment, the MSRP REPORT message 716 does not contain anybody. In this case the start line of the MSRP REPORT message 716 mayinclude a comment describing the USSD Release Complete like e.g. ‘USSDRelease Complete’.

According to another embodiment, other USSD messages than the ones usedin the flow illustrated in FIG. 7 may be exchanged. For example, theUSSD messages given in the left column of table 1 may be used. For eachUSSD message a corresponding MSRP message into which the USSD messagemay be translated according to one embodiment is given in the right handcolumn of table 1.

TABLE 1 USSD message MSRP message Facility (Invoke) SEND Facility(Return result) REPORT or response if sent by non- initiator; or SEND ifsent by initiator Facility (Return error) REPORT or response if sent bynon- initiator; or SEND if sent by initiator Facility (Reject) REPORT orresponse if sent by non- initiator; or SEND if sent by initiator RELEASECOMPLETE REPORT if sent by non-initiator; or SEND if sent by initiator

According to table 1, USSD error and rejection responses may betranslated to MSRP REPORT messages or SEND messages. Such an errorresponse is for example sent if in 707, after the checking the USSDcontent of the first MSRP SEND message 704 an error occurs, e.g. in casecall forwarding is not possible or, in case that instead of callforwarding retrieval of the user's current balance (e.g. prepaid accountbalance) is requested, if the retrieval of the user's balance fails. Inthis case, the USSD AS 702 may for example respond with a REPORT messageindicating that an error has occurred.

The example described above with reference to FIGS. 6 and 7 may be seenas an example for an end device initiated USSD transaction via IMS.

In the following, a further example is given which is based on thecommunication system 500 illustrated in FIG. 5.

In this example, it is assumed that the network provider of the user ofthe communication terminal 501, i.e. the operator of the home network505 of the user, would like to know the amount of free memory stillavailable on the user's SIM (Subscriber Identity Module) card installedin the communication device 501.

The corresponding message flow is illustrated in FIG. 8.

FIG. 8 shows a flow diagram 800 according to an embodiment.

The flow takes place between a SIM card 801, a communication terminal802 (in which the SIM card 801 is installed) corresponding to thecommunication terminal 501, and a USSD AS 803 corresponding to the USSDAS 508.

Analogously as described with reference to FIG. 6, it is assumed thatthe USSD AS 803 has initiated an MSRP session by sending a SIP INVITEmessage to the communication terminal 802.

After session setup, in 804, the network provider's USSD applicationserver 803 generates a USSD message directed to the communicationterminal 802 for querying the free memory amount of the SIM card 801.The USSD message includes particular USSD codes indicating that the USSDmessage should be sent to the user's SIM card 801 and indicating thatthe amount of free SIM card memory is requested.

The USSD AS 803 translates the USSD message into a first MSRP SENDmessage 805. The first MSRP SEND message 805 includes the USSDtransaction identifier (id) as a Message-ID header value. It alsoincludes a ‘text/plain’ Content-Type body including the USSD data. TheByte-Range header field is set to 1-*/* to indicate that the first MSRPSEND message 805 provides the first of several message chunks and thetotal message size is unknown. The Success-Report header field is set to‘yes’ to indicate that MSRP success REPORT messages should be sent back.

The USSD message and the corresponding first MSRP SEND message 805 forexample have the following structure:

USSD message: Transaction identifier: 1234 Message type: RegisterFacility: Invoke = ProcessUnstructuredSS- Request, ussd-String =*13(6)#SEND MSRP message: MSRP dkei38sd SEND To-Path:msrp://user.example.com:8888/9di4eae923wzd;tcp From-Path:msrp://ussd.operator.com:7777/iau39soe2843z;tcp Message-ID: 1234Success-Report: yes Byte-Range: 1-*/* Content-Type: text/plainMessageType:Register Facility:Invoke = ProcessUnstructuredSS-Request,ussd-String = *13(6)#SEND -------dkei38sd+

The USSD AS 803 sets up a Transmission Control Protocol (TCP) connectionto the communication terminal 802 for transporting MSRP messages andassociates the connection with the USSD MSRP session. Then the USSD ASsends the first MSRP SEND message 805 via the established TCP connectionto the communication terminal 802.

When the communication terminal receives the first MSRP SEND message 805it responds in 806 by means of an MSRP 200 OK message 807 to acknowledgethe receipt of the first MSRP SEND message 805 and inspects the contentof the first MSRP SEND message 805 for USSD codes. It finds the USSDcode for SIM forwarding. Therefore, in 808, the communication terminal802 translates the first MSRP SEND message 805 into a first USSD message810 and forwards the first USSD message 810 to the SIM 801 in 809.

The SIM 801 inspects the content of the first USSD message 810 for USSDcodes in 811. It finds the USSD service code for free memory amountquerying and in 812 sends back a second USSD message 813 including thefree amount of memory. The second USSD message 813 also includes a USSDcode indicating that the second USSD message 813 should be forwarded tothe user's home network.

In 814, when receiving the second USSD message 813 from the SIM 801, thecommunication terminal 802 translates it to a first MSRP REPORT message816 and sends the first MSRP REPORT message 816 to the USSD AS 803 in815.

In 817, when receiving the first MSRP REPORT message 816 the USSD AS 803knows from the USSD transaction identifier in the Message-ID header ofthe first MSRP REPORT message 816 that the transported USSD data belongsto the transaction initiated by the USSD memory query previously sent(by means of the first SEND message 805).

In this example it is assumed that the USSD AS 803 extracts the freememory amount information from the first MSRP REPORT message 816 andfinds that the free memory amount is too low. Therefore the USSD AS 803generates another USSD message to request the user's SIM card 801 tofree unneeded memory. The USSD AS 803 translates this USSD message to acorresponding second MSRP SEND message 820. The second MSRP SEND message820 includes the same USSD transaction id as the first MSRP SEND message805 in the Message-ID header to indicate that the included USSD messagebelongs to the same USSD transaction. In 818, the USSD AS 803 sends thesecond MSRP SEND message 820 to the communication terminal 802 via theTCP connection associated with the MSRP session.

The communication terminal 802 acknowledges receipt of the second MSRPSEND message 820 in 819 by means of a second 200 OK message 833.

In 821, the communication terminal 802 translates the second MSRP SENDmessage 818 to a third USSD message 823 and sends the third USSD message823 to the SIM 801 in 822.

In 824, the SIM 801 acknowledges receipt of the instruction to freememory by means of a fourth USSD message 825 which is translated by thecommunication terminal 802 to a second REPORT message 827 which is sentto the USSD AS 803 in 826.

In 828, according to the USSD code for freeing memory in the third USSDmessage 823 the SIM 801 frees unneeded memory.

After the transaction has been completed the USSD AS 803 releases thetransaction by generating a USSD RELEASE COMPLETE message (or USSDrelease message). The USSD AS 803 translates the USSD RELEASE COMPLETEmessage into a third MSRP SEND message 829 and sends it to thecommunication terminal 802 in 834.

The USSD release message and the third MSRP SEND message 829 for examplehave the following structure:

USSD message: Transaction identifier: 1234 Message type: ReleaseComplete Facility: Return result = ProcessUnstructuredSS-Request,ussd-String = MSRP message: MSRP dkei38sd SEND To-Path:msrp://user.example.com:8888/9di4eae923wzd;tcp From-Path:msrp://ussd.operator.com:7777/iau39soe2843z;tcp Message-ID: 1234Success-Report: yes Byte-Range: 89-144/144 Content-Type: text/plainMessageType:Release Complete Facility:Return result =ProcessUnstructuredSS-Request, ussd- String = -------dkei38sd$

In 830, the communication terminal translates the third MSRP SENDmessage 829 into a fifth USSD message 832 which it sends to the SIM 801in 831.

The example described with reference to FIG. 8 can be seen as an examplefor an USSD transaction via IMS initiated by the network side (in thiscase the USSD AS 803).

A further example is described in the following. For this example, acommunication system based on IMS as illustrated in FIG. 9 is assumed.

FIG. 9 shows a communication system 900 according to an embodiment.

The communication system 900 is an IMS communication system, i.e. acommunication system based on IMS. It includes a communication terminal901, in other words an end device, for example a mobile terminal, and avisited (IMS) network 902, i.e. an IMS network which is not operated bythe operator of the home network of the communication terminal 901. Thevisited network 902 includes a P-CSCF (Proxy-Call Session ControlFunction 903), a first I-CSCF 904 (Interrogating-CSCF) and a signalinggateway (SGW) 908.

The communciation system 900 further includes a home IMS network 905 ofthe communication terminal 901 which includes a second I-CSCF 906 and anS-CSCF (Serving-CSCF) 907. Further, the communication system 900includes a PLMN (Public Land Mobile Network) 909. The PLMN 909 may be ahome PLMN 909 of the communciation terminal 901 such that the home IMSnetwork 905 and the PLMN 909 can be seen to form a home network 910 ofthe communication terminal 901.

The communication terminal 901 is connected to the visited network'sProxy-CSCF (P-CSCF) 903. The P-CSCF 903 is connected to the homeoperator's Serving CSCF (S-CSCF) 907 via the first I-CSCF 904 and thesecond I-CSCF 906.

Unlike in the examples described with reference to FIG. 5, the P-CSCF903 is also connected to the home operator's PLMN 909 via the SignalingGateway (SGW) 908. The PLMN 909 includes a USSD server. It should benoted that the SGW 908 may be integrated into the visited P-CSCF or intothe USSD server of the PLMN 909.

It is assumed that the user of the communication terminal 901 is usingthe communication terminal 901 with a prepaid subscription. It isfurther assumed that he would like to know his subscription's currentbalance.

The corresponding message flow is illustrated in FIG. 10.

FIG. 10 shows a flow diagram 1000 according to an embodiment.

The flow takes place between a communication terminal 1001 correspondingto the communication terminal 901, a P-CSCF 1002 corresponding to theP-CSCF 903, an SGW 1003 corresponding to the SGW 908, and a PLMN 1004corresponding to the PLMN 909.

The user initiates the generation of a USSD message by his communicationterminal 1001 for querying the balance. The USSD message includesparticular USSD codes indicating that the USSD message should be sent tothe user's home network 910 and indicating that the current subscriptionbalance is requested.

It is assumed that the home operator's network 910 does not support USSDvia IMS. Therefore, it is assumed that the communication device 901 hasbeen provided with the home network operator's PLMN USSD server addressfor using the USSD service.

In 1005, the communication terminal 1001 generates a SIP INVITE message1006 targeted at the provided home operator's PLMN USSD server forsetting up an MSRP session and sends the message to the P-CSCF 1002.

Since the message is targeted at the home PLMN USSD server the P-CSCF1002 forwards the message to the SGW 1003 in 1007.

The SGW 1003 translates the SIP INVITE message 1006 to a PLMN USSDsignaling 1009 and forwards the signaling information in 1010 to thePLMN 1004, specifically the PLMN USSD server, which may respondaccordingly.

In 1011 the SGW 1003 sends back a first SIP 200 OK message 1012 fornegotiating the SDP (Session Description Protocol) for the MSRP session.The first SIP 200 OK message 1012 includes the address of the SGW 1003in the Contact header field. The first SIP 200 OK message 1012 has forexample the following structure:

SIP/2.0 200 OK    To: <sip:ussd@operator.com>    From:<sip:user@example.com>;tag=xfg9    Call-ID: 3413an89KU    CSeq: 63104INVITE    Contact: <msrp://sgw.operator.com:9999/hgfasd8768754>   Content-Type: application/sdp    c=IN IP4 ims.operator.com   m=message 7654 TCP/MSRP *    a=accept-types:text/plain   a=path:msrp://sgw.operator.com:9999/hgfasd8768754;tcp

In 1013, the communication terminal 1001 acknowledges receipt of thefirst SIP 200 OK message 1012 by means of an ACK message 1014. Thecommunication terminal 1001 stores the SGW address included in the firstSIP 200 OK message 1012 for later setting up an MSRP TCP connection.

After session setup the communication terminal 1001 translates the USSDmessage indicating that the current subscription balance is requestedand generated by the communication terminal 1001 into a MSRP SENDmessage 1016. The MSRP SEND message 1016 includes the USSD transactionidentifier (id) as a Message-ID header value. It also includes a‘text/plain’ Content-Type body including the USSD data. The Byte-Rangeheader field is set to 1-*/* to indicate that the MSRP SEND message 1016provides the first of several message chunks and the total message sizeis unknown. The Success-Report header field is set to ‘yes’ to indicatethat MSRP success REPORT messages should be sent back.

In 1015, the communication terminal 1001 sets up a TCP connection to theSGW 1003 for transporting MSRP messages and associates the connectionwith the USSD MSRP session. The communication terminal 1001 sends theMSRP SEND message 1016 via the established TCP connection to the SGW1003. The TCP connection for MSRP transport is indicated by a dashedarrow 911 in FIG. 9.

In 1017, when the SGW 1003 receives the MSRP SEND message 1016 itresponds by means of a first MSRP 200 OK message 1018 to acknowledge thereceipt of the MSRP SEND message 1016.

In 1019, the SGW 1003 translates the MSRP SEND message 1016 to a firstUSSD message 1021 and in 1020 forwards the USSD message 1021 to the PLMN1004 (i.e. the home PLMN USSD server).

In 1022, the PLMN 1004 (i.e. the PLMN USSD server) finds the USSDservice code for balance querying and responds in 1023 by means of asecond USSD message 1024 including the current balance information. Thesecond USSD message 1024 includes a code indicating that the messagecontent should be presented to the user.

The second USSD message 1024 is sent from the PLMN USSD server to theSGW 1003. In 1025, the SGW 1003 translates the received second USSDmessage 1024 to an MSRP REPORT message 1027 and in 1026 sends it to thecommunication terminal 1001.

In 1028, when receiving the MSRP REPORT message 1027, the communicationterminal 1001 inspects the content of the MSRP REPORT message 1027 forUSSD codes. It finds the code for user presentation and displays theUSSD message's content (the current balance information) for the user.

In one embodiment, instead of including USSD data in MSRP message bodieswith Content-Type ‘text/plain’ the USSD data may be included with otherContent-Types, e.g. with a special USSD Content-Type ‘application/ussd’.

According to one embodiment, USSD messages may target the visitednetwork 502, 902 by targeting the SIP INVITE message for setting up theMSRP USSD session at the visited USSD AS (i.e. at a USSD AS of thevisited network 502, 902). In case that the communication terminal 501,901 does not know the visited USSD AS's address then the SIP INVITEmessage may be targeted at a generic visited USSD AS address like e.g.‘visitedUSSDASgvisitedOperator.com’. In this case the P-CSCF 503, 903may for example provide the address of the visited operator's USSD AS inthe SIP 200 OK message replied to the SIP INVITE message (similar to theprovision of the SGW address with the first 200 OK message 1012 in theflow of FIG. 1000).

Whether the communication terminal should target its USSD messages atthe home operator or at the visited operator may be decided by thecommunication terminal depending on USSD codes for network forwardingincluded in the USSD messages to be sent. For example, if home networkforwarding is indicated then the home operator's USSD AS or PLMN USSDserver is targeted and if visited network forwarding is indicated thenthe visited operator's USSD AS or PLMN USSD server is targeted.

According to one embodiment, instead or in addition of indicating theMSRP address for USSD network service in the Contact header field of aSIP 200 OK message the address may be indicated in the SIP message'sbody, e.g. in its SDP body, for example as follows:

SIP/2.0 200 OK    To: <sip:ussd@operator.com>    From:<sip:user@example.com>;tag=xfg9    Call-ID: 3413an89KU    CSeq: 63104INVITE    Contact: <msrp://sgw.operator.com:9999/hgfasd8768754>   Content-Type: application/sdp    c=IN IP4 ims.operator.com   m=message 7654 TCP/MSRP *    a=accept-types:text/plain   a=path:msrp://sgw.operator.com:9999/hgfasd8768754;tcp

In one embodiment, if an MSRP session has already been set up for homeoperator targeted USSD but not for visited operator targeted USSD, andif a new USSD transaction is targeted at the visited operator then a newMSRP session may be set up targeting the visited operator and viceversa.

While the invention has been particularly shown and described withreference to specific embodiments, it should be understood by thoseskilled in the art that various changes in form and detail may be madetherein without departing from the spirit and scope of the invention asdefined by the appended claims. The scope of the invention is thusindicated by the appended claims and all changes which come within themeaning and range of equivalency of the claims are therefore intended tobe embraced.

1. A communication device comprising: a determining circuit configuredto determine, for a first message formed in accordance with a firsttransmission protocol indicating an information to be transmitted aspart of a message exchange, whether or not the first message is amessage directed to an initiator of the message exchange; a selectingcircuit configured to select a type of message according to a secondtransmission protocol based on whether or not the first message isdirected to the initiator of the message exchange; and a messagegenerating circuit configured to generate a second message of theselected type according to the second transmission protocol indicatingthe information.
 2. The communication device according to claim 1,further comprising a transmitter configured to send the generated secondmessage.
 3. The communication device according to claim 1, wherein thedetermining circuit is configured to determine whether the first messageis directed to the initiator or to a non-initiator of the messageexchange.
 4. The communication device according to claim 1, wherein theinformation is included in the first message.
 5. The communicationdevice according to claim 1, wherein the message generating circuit isconfigured to generate the second message to comprise the information.6. The communication device according to claim 1, wherein the secondprotocol is the Message Session Relay Protocol.
 7. The communicationdevice according to claim 1, wherein the first protocol is theUnstructured Supplementary Service Data protocol.
 8. The communicationdevice according to claim 7, wherein the message exchange is anUnstructured Supplementary Service Data transaction.
 9. Thecommunication device according to claim 1, wherein the message exchangeis carried out in a communication session.
 10. The communication deviceaccording to claim 1, wherein the message exchange is carried outbetween the communication device and another communication device. 11.The communication device according to claim 1, being a communicationterminal.
 12. The communication device according to claim 1, being acommunication server on the network side of a communication system. 13.The communication device according to claim 1, operating as a gatewaybetween two communication systems.
 14. A method for generating a messagecomprising: determining, for a first message formed in accordance with afirst transmission protocol indicating an information to be transmittedas part of a message exchange, whether or not the first message is amessage directed to an initiator of the message exchange; selecting atype of message according to a second transmission protocol based onwhether or not the first message is directed to the initiator of themessage exchange; and generating a second message of the selected typeaccording to the second transmission protocol indicating theinformation.
 15. A communication device comprising: a message generatingcircuit configured to generate, for each first message of a sequence offirst messages formed in accordance with a first application layertransmission protocol indicating an information, a part of a secondmessage according to a second application layer transmission protocolindicating the information, wherein the parts of the second messageaccording to the second application layer transmission protocol eachcomprise an identification of the second message.
 16. The communicationdevice according to claim 15, further comprising a transmitterconfigured to transmit the parts of the second message.
 17. Thecommunication device according to claim 16, wherein the transmitter isconfigured to transmit the parts of the second message in acommunication session.
 18. The communication device according to claim16, further comprising a receiver configured to receive a responsemessage to at least one part of the second message.
 19. Thecommunication device according to claim 18, wherein the messagegenerating circuit is configured to generate the parts of the secondmessage such that a sequence of parts of the second messagecorresponding to the sequence of first messages is generated and isconfigured to generate, for the at least one part of the second message,the part of the second message only after the response message to thepart of the second message preceding the part of the second message inthe sequence of parts of the second message has been received by thereceiver.
 20. The communication device according to claim 19, whereinthe message generating circuit is configured to, for the at least onepart of the second message, generate the part of the second message inresponse to the response message.
 21. The communication device accordingto claim 16, further comprising a receiver configured to receive aresponse message to each part of the second message.
 22. Thecommunication device according to claim 21, wherein the messagegenerating circuit is configured to generate the parts of the secondmessage such that a sequence of parts of the second messagecorresponding to the sequence of first messages is generated and isconfigured to generate, for each part of the second message but thefirst part in the sequence of parts of the second message, the part ofthe second message only after the response message to the part of thesecond message preceding the part of the second message in the sequenceof parts of the second message has been received by the receiver.
 23. Amethod for generating a message comprising: generating, for each firstmessage of a sequence of first messages formed in accordance with afirst application layer transmission protocol indicating an information,a part of a second message according to a second application layertransmission protocol indicating the information, wherein the parts ofthe second message according to the second application layertransmission protocol each comprise an identification of the secondmessage.